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What is a System? NASA’s Phased Project 
Description 

From the MSFC Systems Engineering Handbook (1991) 


Systems engineering is defined in MIL-STD- 
499A as 

. . . the process(es) required to trans- 
form an operational need into a 
description of system performance 
parameters and a system configuration 
through the use of an iterative process 
of definition, synthesis, analysis, de- 
sign, test and evaluation. It includes 
the integration of related technical 
parameters and ensures compatibility 
of all physical, functional, and program 
interfaces in a manner that optimizes 
the total system definition and design. 

In addition, systems engineering 
integrates reliability, maintainability, 
safety, survivability, and other such 
efforts into the total engineering effort 
to meet cost, schedule and technical 
performance objectives. ( Engineering 
Management, May 1, 1974) 

Systems engineering is a continuous, 
iterative process that has a built-in feedback 
mechanism. It is used throughout a project 
or program’s life cycle to arrive at the best 
system architecture and design possible. 
Just when systems engineering began to be 
practiced as a separate discipline is open to 
debate, but there seems to be general agree- 
ment that formal recognition and definition 
of the process started after World War II. 
Large, complex post-war development 
projects such as the first U.S. ballistic 
missiles and NASA’s Apollo program exhib- 
ited the characteristics which created the 
need for systems engineers. 

Among these project characteristics are: 

• Large design teams with many highly 
specialized designers 

• Many contractors involved, widely sepa- 
rated geographically, complicating com- 
munications 
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• Many hardware and software systems in 
concurrent development 

• Complex operational and logistic support 
requirements 

• Constrained development time 

• High level of advanced technology 
( Systems Engineering Management 
Guide, U.S. Government Printing Office, 
1986). 

There are many definitions of a system. Two 
of these are listed below: 

• A system is a set of interrelated compo- 
nents working together toward some com- 
mon objective. (Blanchard, Benjamin S. 
and Fabrycky, Wolter J., Systems Engi- 
neering and Analysis, Prentice Hall, Inc., 
1990) 

• A system is a grouping of parts that 
operate together for a common purpose. 
For example, an automobile is a system of 
components that work together to provide 
transportation. An autopilot and an 
airplane form a system for flying at a 
specified altitude. (Forrester, Jay W., 
Principles of Systems, Wright -Allen Press 
Inc., 1968). 

Systems engineering is a cyclical process as 
depicted in Figure 1. The terms shown in 
this figure are explained in the following 
paragraphs. 

1. Project and Mission Requirements/ 
Need Definition can also be termed as “cus- 
tomer engineering.” It is the process by 
which the needs of the customer (the princi- 
pal investigator or other significant parties, 
such as Congress or other budgetary author- 
ity) are determined. This allows the systems 
engineer to define requirements for a system 
that will meet the needs of the customer . 
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1. Project and Mission Requirements/Need Definition 



Figure 1 Systems Engineering Cycle 


2. Risk Analysis/Management is a 
continuing process to identify and assess the 
risks involved with the development and 
operation of the system. These include tech- 
nical, schedule, cost and organizational 
risks. Following the identification of the 
risks involved, the system engineer then de- 
velops an implementation plan to control 
and, if possible, reduce risks. 

3. Systems Analysis involves under- 
standing how the key mission and system 
functional elements interact. The mission 
analysis translates the users’ needs into 
functional/performance requirements and 
design constraints. A functional analysis 
takes these requirements and breaks them 
down into specific tasks. 

4. Concept Development is the process of 
making i nformed t rade-offs among the var- 
ious options to select the one that best meets 
the requirements and design constraints. 
Preliminary design and performance re- 
quirements and implementation architec- 
ture are the results. 


5. Derived Requirements Definition is 
the process of translating mission and func- 
tional analysis results, system operational 
concepts, and the selected system architec- 
ture into a set of system performance and 
interface requirements. At this level, the 
requirements must specify either functional 
or interface criteria only, without presenting 
design solutions. This gives the detail 
designers the flexibility needed to arrive at 
design solutions that meet the requirements. 

6. Implementation Planning and Sys- 
tems Integration is a complex activity 
resulting in a coherent, integrated set of 
implementation tasks and responsibilities 
for the design, development, fabrication, ver- 
ification and operation of the required 
system. It requires negotiation between the 
system requirements definition personnel 
and the system implementation (develop- 
ment) personnel. The plan must also consid- 
er the project constraints of schedule and 
budget while avoiding unnecessary risk. 
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7. Configuration Management activities 
ensure that controlled definition of all 
engieering documentation is maintained and 
correct information is distributed to all 
appropriate parties in a timely manner. This 
is one of the most important responsibilities 
of the systems engineering organization. On 
larger programs that have large numbers of 
people involved, this process becomes even 
more critical. This activity is also the mecha- 
nism by which the system development 
process is documented (i.e., design knowl- 
edge capture). 

Configuration Management establishes 
the system to control the requirements and 
configuration of hardware and software, 
evaluate changes, and maintain the defini- 
tion of the configuration via baselined docu- 
mentation and released drawings. 

8. Technical Oversight serves two func- 
tions. First, it ensures that all the subsys- 
tems work together. Second, it implements 
mechanisms to guarantee that the developed 
and documented architectural concept is not 
inadvertently changed during the develop- 
ment process. This allows the developer to 
certify that the system, which is ultimately 
tested, will meet the customer’s require- 
ments. Technical oversight consists of the 
technical reviews and audits that gather 
consensus from all parties involved to ascer- 
tain that the effort at any given time is 
correct and adequately planned for the 
continuance of the work. 

A specific task for the systems engineer 
to perform is assuring that the systems re- 
quirements are understood and correctly 
implemented by the design organizations. 
This responsibility requires the systems 
engineer to work closely with the design 
organizations throughout the program. At 
the same time, the systems engineer must 
recognize that the initial set of systems 
requirements will not be perfect. During 
design evolution or because of the inability of 
a subsystem to meet its intended functional 
requirements, changes in the systems 
requirements will be necessary, and the 


systems engineer should view these changes 
as a normal part of the design process. Avoid 
the tendency to view the Systems Require- 
ments Specification as something, once base- 
lined, that is final and unchangeable. 

9. During the Verification and Valida- 
tion portion of the development activity, the 
characteristics and performance of the sys- 
tem are compared to the requirements and 
specifications. Tests, analyses and demon- 
strations are performed to verify that the 
hardware and software satisfactorily meet 
the performance requirements of the system 
specifications. 

NASA Phased Project description 

In the planning of major projects, critical 
requirements must be well defined and the 
necessary technology must be available. If 
these criteria are met, there will be an ac- 
ceptable level of risk in meeting technical 
goals with reasonable cost and schedule. 

To ensure that the program is at a proper 
level of maturity when Congress approves 
major funding for design and development, 
projects go through various phases of analy- 
sis and definition. There are five phases in 
the life cycle of a typical successful project: 
pre-Phase A (concept study), Phase A 
(preliminary analysis), Phase B (definition), 
Phase C (design) and Phase D (development/ 
operations). Depending on the complexity of 
the system, funding availability and launch 
schedules, a project may combine phases or 
add intermediate phases. Common 
variations would include combining pre- 
Phase A and Phase A, adding an advanced 
development phase between Phase B and 
Phase C, combining Phase C and Phase D 
into Phase C/D, or moving operations out of 
Phase D into a separate phase. As a further 
example, the Space Shuttle program had 
both a Phase B' (B prime) and Phase B" (B 
Double-prime) in order to further refine the 
definition and requirements of the system 
before proceeding into Phase C. Figure 2 
depicts a typical phased project flow in which 
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MAJOR MANAGEMENT DECISIONS 


PRE-PHASE A J 
PHASE A 
PRELIMINARY 
ANALYSIS 


• Develop Project 
Objectives 

• Assess Feasibility 

• Identify Research and 
Advanced Technology 
Requirements 

• Identify Support 
Requirements Areas 

• Develop Gross Plana for 
Implementation 

• Perform Trade-Off 
Analysis 

• Identify Favorable and 
Unfavorable Factors 

• Define Relationships to 
Programs 

• Perform Cost Analysis 


T 


I 


Feasible Project Concepts for 
Detailed Study 


PHASE B 
DESIGN 


• Refine Selected 
Alternative Concepts 

• Conduct Systems 
Analysis 

9 Develop Preliminary 
Requirement and Design 
Specifications 

• Define Support 
Requirements 

• Assess Preliminary 
Manufacturing and Teat 
Requirements 

• Identify Advanced 
Technology and 
Advanced Development 
Requirements 

• Assess Costs and 
Schedules 

• Define Management 
and Procurement 
Approaches 

• Perform Trade-off 
Analysis 

• Perform Operation 


T 


"^( 2 ) 


• Preliminary Design and 
Specifications 

• Preliminary Schedule, 
Resource and Management 
Plans 

• WBS 


(1) Mission need statement approved 

(2) Mission need statement reaffirmed 


PHASE C 
DESIGN 


• Develop Detail of 
Selected Concept 

• Develop Specific 
Requirements and 
Design Specifications 

• Develop Plans for 
Manufacturing, Testing, 
Operations, Supporting 
Systems, Facilities, etc. 

• Initiate Required 
Long Lead Advance 
Development and Define 
Plan for Supporting 
Development 

• Develop Schedules and 
Estimates of Costs 

• Refine Management and 
Procurement Plans 


T 


PHASED 

DEVELOPMENT/ 

OPERATIONS 


• Develop and Test 

• Manufacture 

• Checkout 

• Operate 

• Evaluate 

• Distribute Results 


T 


• Project Design and 
Specification including 
Manufacture Test and 
Operation Plans 
m Schedule Resources 
Management and 
Procurement Plans 


Completed Project 


Source: MM7120.2, Project Management Handbook 


Figure 2 NASA Program Phases 


pre-Phase A has been combined with 
Phase A. 

Safety is a critical systems engineering 
function that must be considered during all 
program phases and in all studies and analy- 
ses. In short, although safety is organization- 
ally the responsibility of S&MA, it is a 
responsibility of all program participants 
and should be a primary consideration 
throughout the systems engineering process. 

Figure 2 shows the major activities in 
each phase, as well as the outputs and major 


decision points. Note that this description 
pertains to the typical program, in which 
NASA contracts with industry to do the 
Phase C/D activity. Other types of programs 
include small, contracted efforts, as well as 
both large and small in-house programs 
where NASA may retain all or part of the 
design and development responsibility. 

The typical program review phasing 
includes many more activities and formal 
reviews than are shown in Figure 2. For 
completeness, these are introduced here and 
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PRR PDR CDR AR 




Notes: 


PRR - Preliminary Requirements Review 

PDR - Preliminary Design Review 

CDR - Critical Design Review 

AR * Acceptance Review 

ATP - Authority to Proceed 

IPL - Integrated Payload 


RR - Requirements Review 
GOR - Ground Operations Review 
FOR - Flight Operations Review 
IRR - Integrated Readiness Review 
FRR * Flight Readiness Review 


Figure 3 Typical Program Review Phasing 


shown in Figure 3. This figure also serves to 
relate the major reviews to the project 
phases and to show the more detailed inte- 
gration activities associated with attached 
payloads and Spacelab-kinds of experiments. 

At MSFC, the Program Development 
(PD) Directorate is responsible for nurturing 
new projects from idea conception through 
concept definition supporting preliminary 
design. Systems engineering is emphasized 
and utilized throughout this process, both in- 
house and during contracted studies. Typi- 
cally, concepts that have matured through 
this process and gained Congressional new 
start approval to become official projects are 
then moved into project offices. The new 
start review and approval process begins ap- 
proximately two years in advance of Phase 
C/D authority to proceed (ATP) at which 
point funds are applied to begin a major 
design and development effort. That two- 


year period is used to execute the definition 
phase (Phase B) and prepare the request for 
proposal (RFP) for Phase C/D. The new start 
approval process includes a definition review 
or non-advocate review (NAR) generally con- 
ducted during the Phase B activity at a time 
when the project manager, Center manage- 
ment, and Headquarters program office 
deem appropriate. Results of the NAR are 
factored into the Phase C/D RFP, as well as 
the budget approval process. Note that this 
timeline pertains principally to large pro- 
grams which include in-house and contract- 
ed efforts. The timeframe could be much 
shorter for smaller projects such as experi- 
ments. Figure 4 shows the overall systems 
engineering process flow in Program Devel- 
opment (PD). 

In the course of developing the pre- 
liminary systems requirements and the 
conceptual design, PD uses many of the same 
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* Headquarters Approval Lead to 
Program Initiation Agreement 


Figure 4 Systems Engineering Process Flow in Program Development 


analysis tools and techniques that are em- 
ployed by Science & Engineering (S&E) in 
later program phases. The principal differ- 
ences in the outputs of the two organizations 
are the quantity, format and maturity of the 
documentation and the level of detail in the 
analyses. In summary, the analyses and 
trade studies by S&E are to refine, not re- 
peat, the concepts developed by PD in sup- 
port of design implementation. PD develops 
the conceptual approach and S&E develops 
the design implementation. 

Pre-Phase A (Concept Study) 

A pre-Phase A study may be accomplished 
within the engineering capability of Pro- 
gram Development or contracted with 
funding from one of the major NASA Head- 
quarters offices. Successful results from this 
study would provide justification to initiate a 
Phase A study or additional pre-Phase A 
studies. The genesis of new ideas requiring 


further study can come from a variety of 
sources: industry, the scientific community, 
university and research centers, MSFC con- 
tractors and associates, or even from within 
MSFC itself. Typically, such ideas receive a 
top-level examination by cognizant 
MSFC/PD personnel. A quick assessment of 
objectives, requirements and the total mis- 
sion concept is performed. Often, new ideas 
are shared with colleagues through propos- 
als (either in response to an RFPor unsolicit- 
ed), technical papers at professional society 
meetings, or “white papers” propounding the 
new idea/concept. From an MSFC in-house 
weeding out process, concepts are identified 
for further (Phase A) study. 

System functional concept trades are per- 
formed during the pre-Phase A period, 
generally at a fairly cursory level of detail. 
This process eliminates architectures that 
are too costly or time-consuming to develop. 
They are conducted at a level sufficient to 
support the definition of the top-level system 
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requirements. Architectural options are the 
result. Some of the primary sources for this 
identification of concepts include brain- 
storming, past experience, examination of 
other systems and intuition. 

Cost estimates are developed in pre- 
Phase A and are usually at a very prelimi- 
nary level due to the lack of detailed systems 
definition. These estimates are based pri- 
marily on parametrics adjusted for the new 
program, taking into account differences in 
mission, size, complexity and other factors. 

PHASE A (PRELIMINARY ANALYSIS) 

A Phase A study is the preliminary analysis 
of a space concept. These concepts could have 
come from a pre-Phase A study or from other 
sources within or external to NASA. The ma- 
jority of concepts that are studied at MSFC 
are assigned by NASA Headquarters and 
funded accordingly. Documentation in this 
Phase usually consists of study reports and 
briefing charts. 

Schedules are developed during Phase A 
studies by Program Development in conjunc- 
tion with the organization performing the 
study (contractor, PD, S&E). The schedules 
include an overall program schedule pro- 
vided by MSFC and a detailed technical 
schedule developed by the contractor. 

The overall program schedule depicts im- 
portant milestones that establish the start 
and finish dates of each study phase, includ- 
ing design, development, launch, and oper- 
ations. Programmatic milestones are also 
shown. These are dependent on the federal 
budget cycle plus proposal preparation and 
evaluation time. The contractor schedule 
depicts the major activities and phasing 
required to develop the hardware in time to 
meet the scheduled launch date. Since this is 
a concept study, the detail schedule is still at 
a relatively high level and would not show 
activity below the system level. 

Cost estimates developed during Phase A 
are generated using a parametric cost 
analysis system in conjunction with the cost 


database discussed above. The has access to 
several cost estimating systems, both 
government and commercial. One example is 
the GE/RCA Price Model. Each model is 
unique with special capabilities and limita- 
tions. Complexity factors and Cost Estimat- 
ing Relationships are applied to the 
estimating, software using system weight as 
the independent variable. A factor is applied 
to the hardware/software costs to account for 
wraparounds such as project management, 
test and verification, percent new design, 
operational complexity, hardware complex- 
ity, similarity to other projects or develop- 
ment activities and others. As each system is 
defined in more detail and the system weight 
is further refined, the cost estimates become 
more realistic and provide a higher confi- 
dence level in the results. 

A cost/risk analysis and assessment is 
usually completed near the end of each 
Phase A study. The analysis is accomplished 
with special software that uses statistical 
techniques, including a Monte Carlo simula- 
tion. The results predict the probability of 
completing the program within the estimat- 
ed cost. A risk assessment, which follows the 
analysis, should identify areas of high risk 
that require further cost analysis or possibly 
further trade studies to look at alternate sys- 
tems that would lower the potential costs 
without sacrificing technical capability. 

As part of the study activity, the contrac- 
tor provides a detailed risk analysis and 
assessment to establish a high level of confi- 
dence for the program cost. The cost estimate 
established during this phase will provide 
NASA Headquarters with the funding 
requirements to be approved by Congress 
before the development program can begin. 

The processes occurring during Phase A 
include: 

• Development of project objectives 

• Assessment of project feasibility 

• Identification of research and advanced 

technology requirements 
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• Identification of support requirements 
areas 

• Performance of trade-off analyses 

• Identification of favorable and unfavor- 
able factors 

• Definition of relationships to other 
programs 

• Selection of systems concepts 

• Identification of maintenance, technology 
insertion, and disposal concepts of 
payload and orbital debris 

• Environmental Impact Analysis. 

The outputs from Phase A, which become the 
inputs to Phase B, are in the form of reports 
or annotated briefing charts and include in- 
formation on: 

• Concept definition 

• Preliminary system requirements 

• Preliminary configuration layouts 

• Point designs 

• Preliminary implementation plans 

• Preliminary schedules 

• Preliminary cost estimates 

• Environmental impact. 

Phase B (Definition and 
Preliminary Design) 

This phase of the project consists of the re- 
finement of preliminary requirements, cost 
estimates, schedules and risk assessments 
prior to starting final design and develop- 
ment. 

Once the feasibility of an idea is estab- 
lished, the concept definition phase is begun 
to explore alternatives to meet the docu- 
mented mission need. Competition and inno- 
vation should be employed to ensure that a 
wide variety of alternatives are identified 
and examined. Modeling and computer ana- 
lysis are required to assess the best concepts. 

The goal of a concept definition activity is 
to determine the best and most feasible 
concept(s) that will satisfy the mission and 
science requirements. Generally, the re- 
quirements available at this point in time 


are Level I (NASA Headquarters) require- 
ments from preliminary activities. 

Level I requirements are broad mission 
needs and objectives. Occasionally, there 
may be some Level II (project office level) re- 
quirements at this time. 

The mission need determination is the 
first step in a multifaceted preliminary con- 
cept definition activity. This is the step that 
is first performed at a NASA Headquarters 
or Center level (or industry, university, etc.) 
and is the precursor to concept development. 
The mission need determination is that part 
of early mission planning that identifies a 
scientific knowledge need or gap that could 
be met with some kind of NASA sponsored 
activity. A set of Level I requirements is gen- 
erally developed during or just prior to the 
activities described in the following para- 
graphs. 

A feasibility analysis is conducted to de- 
termine the viability of the project. The 
study report usually includes requirements, 
objectives, problems, opportunities and costs. 

A utility analysis is then conducted to de- 
termine the value of a project. The following 
criteria may be considered during this study: 
the needs met, the scientific knowledge ac- 
quired, the political benefits, or potential 
spinoffs and applications. 

Certain satellites and/or instruments are 
selected for a more detailed level of design. 
The Preliminary Design Office of Program 
Development performs these studies. This 
office is a miniature replication of the capa- 
bilities of the laboratories at MSFC: Propul- 
sion, Guidance, Navigation and Control, 
Electrical Power, Avionics, Structures, 
Operations, etc. One difference is the empha- 
sis by Program Development in developing 
credible cost estimates. Cost is an important 
differential, but often other factors, such as 
mission risk or incompatibility with other 
instruments that may be grouped on a com- 
mon satellite, may predominate. 

Throughout the Phase B period the con- 
cepts that were developed during Phase A 
are iteratively reviewed and analyzed. Using 
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trade study techniques, the concepts’ capa- 
bilities are compared to the system require- 
ments. Those concepts that consistently 
satisfy the requirements are identified and 
refined. Any concepts that do not meet 
performance and other requirements are 
scrutinized very closely for possible elimina- 
tion. Following the examination of those 
that do not perform well, assessments are 
made regarding their augmentation to dis- 
cover the degree of change necessary to bring 
their performance into scope. The concepts 
that have to change too much or would 
experience severe budgetary and/or schedule 
impacts are deleted from the concept defini- 
tion and analysis cycle. This allows the ana- 
lysts’ energies to be focused on those concepts 
that are valid and workable. 

These trade studies provide a more de- 
tailed look at the architectural concepts and 
result in a narrowing of the field of candi- 
dates. Trades performed during this time 
consider such things as cost, schedule, life- 
time and safety. The evaluation criteria used 
to assess alternative concepts are developed 
to a finer level of detail than for earlier sys- 
tem trades. 

Cost estimates from Phase A are refined 
as further detailed requirements are identi- 
fied during Phase B. The cost estimating 
process is still dependent on parametric ana- 
lysis. The Program Development cost office 
works closely with the study contractor in 
evaluating costing methodology and continu- 
ously compares government cost estimates 
with those of the study contractor. Should a 
large discrepancy occur, the assumptions 
and schedule inputs of the study contractor 
are examined. If this examination yields val- 
id assumptions and schedules, the NASA 
estimates are adjusted. The cost estimation 
process goes through continuous iterations 
during the study to reflect the evolution of 
detail resulting from trade studies. 

Schedules are developed during Phase B 
by the task team program control personnel 
and by the study contractors. Schedules de- 
veloped by the task team are expanded from 


the Phase A overall program schedules. In 
addition, other schedules are developed that 
include Phase C and D procurement strate- 
gies, cost phasing and project manning 
requirements. The study contractor sched- 
ules are expanded to lower levels of the work 
breakdown structure (WBS) to include 
subsystem development, program manage- 
ment, manufacturing, verification, logistics 
planning, operations planning and other 
technical areas. The schedule detail would 
show the phasing of all major activities 
through launch and the follow-on operations. 

As in Phase A, the typical documentation 
of this phase consists of reports and briefing 
charts. 

The processes occurring during Phase B 
include: 

• Refinement of selected alternative 
concepts 

• Performance of trade-off analyses 

• Performance of system analyses and 
simulations 

• Definition of preliminary system and 
support requirements 

• Definition and assessment of preliminary 
manufacturing and test requirements 

• Identification of advanced technology and 
advanced development requirements for 
focused funding 

• Refinement of preliminary schedules 

• Refinement of preliminary cost estimate 
and trade study results which support 
selection of baseline for cost estimate 

• Assessment of technical, cost, and sched- 
ule risks 

• Assessment and refinement of the Mis- 
sion Need Statement. 

The outputs from Phase B, which become the 
inputs to Phase C, may include (in the form 
of study reports and annotated briefing 
charts) information related to: 

• Preliminary WBS 

• System requirements 

• Preliminary interface requirements 
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PHASE A 
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Definition 

PHASE C 
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Source: PD Lead Engineer’s Guide 
Figure 5 MSFC Support Relationships in Project Phases 


• Management and procurement ap- 
proaches 

• Program Implementation Plans 

• Request for Proposal (RFP) inputs, where 
applicable. 

Phase B is normally the final phase of 
activity within Program Development. A 
separate core of people is selected to form a 
task team to manage the Phase B contract. 
At the beginning of Phase B, a chief engineer 
is appointed to the task team (or project 
office) to provide consultation to the task 
team manager on all related engineering 
matters. The chief engineer also helps 
ensure that the study contractor uses accept- 
able engineering practices and sound 
judgment during the course of the study. The 


chief engineer is often the deputy to the task 
team manager and is usually the first Sci- 
ence and Engineering representative sub- 
stantially involved in the process. The chief 
engineer’s office has personnel resources 
available to support the project as needed 
during the study. Additional engineering 
support from S&E may be used at the discre- 
tion of the chief engineer. The chief engineer 
plays a key role in determining the state of 
technical maturity of the project for starting 
the design and development phase. 

At the conclusion of Phase B, the task 
team is converted to a project office, and it is 
no longer under the direction of program 
development. On large projects, such as 
Space Station, a project office might be 
created prior to Phase B; in that case, 
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Program Development (PD) support becomes 
minimal (such as cost estimating and limited 
programmatics) and S&E plays a major role 
in the Phase B engineering activities. 

At MSFC, it is not uncommon to have 
more than one directorate providing 
engineering or technical support to a project 
throughout its life cycle. The transition of 
engineering support is depicted in Figure 5. 

Figure 5 shows that Program Develop- 
ment typically performs most, if not all, of 
the technical support during Phase A. As the 
project life cycle evolves, the S&E Director- 
ate takes on a larger and larger role as PD’s 
involvement tapers off. The exact point at 
which S&E gets involved varies depending 
on the size and priority of the project at 
MSFC, as well as the availability of S&E 
manpower resources. In every case, however, 
Phase C and D activities are exclusively the 
domain of S&E. 

The extent of information and the level of 
detail available at the end of Phase B to 
begin the Phase C design are variable and 
become a function of the time and money 
made available to the PD organization for 
the conduct of Phase B studies. As a result, 
significant efforts may be needed at the 
beginning of Phase C to refine many of the 
Phase B analyses. 

The hand-over of technical responsibility 
from PD to S&E is an interface which 
requires a great deal of attention to mini- 
mize transition problems and project 
disruptions. A key issue to be addressed is 
the type and content of documentation 
produced in Phases A and B. Since these 
early phases typically have limited funding 
and PD’s manpower resources are limited, 
requirements and specifications resulting 
from Phase B may require substantial 
refinement and rework by S&E at the 
beginning of Phase C. It is important that 
Phase C planning and schedules account for 
this activity. 


PHASE C (DESIGN) 

This phase requires Congressional budget 
approval for projects large enough to be 
separate line items in the NASA budget 
submission. Funding must be approved and 
available at the start of Phase C. Detailed 
design is accomplished and plans are refined 
for final development, fabrication, test and 
operations. 

The processes occurring during Phase C in- 
clude: 

• Refinement of work breakdown structure 

• Development of Systems Requirements 
Specification 

• Development of design and contract end 
item specifications 

• Development of interface requirements 
documents 

• Completion of preliminary and detail 
design 

• Development of preliminary interface 
control documents (ICDs) 

• Performance of detailed system analyses 

• Development of manufacturing, testing 
verification, integration, operations, sup- 
porting systems and facilities plans 

• Definition of a development plan 

• Refinement of schedules and cost esti- 
mates 

• Refinement of management and procure- 
ment plans. 

The outputs from Phase C, which become the 
inputs to Phase D, include: 

• Updated system requirements documen- 
tation 

• Updated detail design and CEI specifica- 
tions 

• Baseline. 
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It is typically at the beginning of Phase C, 
when industry is heavily involved in design 
and project funding is increased dramatical- 
ly, that many formal documentation require- 
ments are contractually imposed. This can 
contribute to large cost increases over 
previous estimates in Phases A and B, and 
dictates the need for early inputs from the 
S&E engineering organization to assure that 
design and performance requirement specifi- 
cations and data requirements are incorpo- 
rated into initial cost estimates. 

Phase D (Development/Operations) 

During this phase of a project, flight hard- 
ware and software are developed, manufac- 
tured/coded, tested and qualified for flight. 
In addition, support is provided for the 
follow-on flight operations. 

The processes occurring during Phase D in- 
clude: 

• Development and test of prototype and 
protoflight hardware 

• Verification /V alidation - qualification of 
hardware and software for flight 

• Manufacture and integration of flight 
hardware 

• Checkout of flight systems 

• Launch operations 

• Flight operations 


• Retrieval or disposal of payload and orbit- 
al debris. 

The outputs from Phase D include: 

• A successful mission, 

• Documentation and evaluation of the re- 
sults and anomalies 

• Documentation of lessons learned. 

In the early days of spaceflight, MSFC 
provided expendable propulsion systems, so 
most project activity terminated when 
launch operations were complete. As the 
mission of MSFC evolved into payloads and 
experiments, its role in the area of mission 
operations and maintenance greatly expand- 
ed and now provides an important function 
in present projects such as Spacelab, the Na- 
tional Space Transportation System, Hubble 
Space Telescope, the Advanced X-Ray Astro- 
physics Facility, and Space Station Freedom. 
These programs involve 15 to 30 years of 
technology insertion, operations and main- 
tenance activities that would justify a sepa- 
rate independent phase in their life cycles. 

At MSFC, the design phase is normally 
combined with the development and oper- 
ations phase to form a Phase C/D. The result- 
ing contract takes the Phase B data, refines 
it into a final design, develops and fabricates 
the hardware, tests and flight qualifies it, 
and supports the flight and mission 
operations. 


